Многие администраторы платформы VMware vSphere очень часто интересуются вопросом замены сертификатов для серверов ESXi в целях обеспечения безопасности. Как правило, это просто инструкции, которые не дают понимания - а зачем именно нужно менять эти сертификаты.

Недавно VMware выпустила интересную статью на тему сертификатов в vSphere и других продуктах, приведем ниже основные выдержки из нее.

1. Сертификаты - это вопрос доверия и шифрования.

При соединении с различными веб-консолями компонентов инфраструктуры VMware vSphere используется протокол HTTPS, где S означает "Secure". Инфраструктура SSL, а точнее ее последователь Transport Layer Security (TLS), использует известный в криптографии принцип открытого и закрытого ключей, который позволяет узлам, доверяющим друг другу безопасно обмениться информацией по шифрованному каналу.

TLS развивается по следующему пути:

• Версия 1.0 имеет уязвимости, он небезопасен и больше не должен использоваться.
• Версия 1.1 не имеет таких уязвимостей, как 1.0, но использует такие алгоритмы шифрования, как MD5 и SHA-1, которые больше не считаются безопасными.
• Версия 1.2 добавляет шифрование AES, которое работает быстро и не использует небезопасные методы, сам же алгоритм использует SHA-256. На текущий момент это стандарт TLS.
• Версия 1.3 не содержит слабых точек и добавляет возможности увеличения скорости соединения, этот стандарт скоро будет использоваться.

Если вы используете сертификаты vSphere, то независимо от того, какие они (самоподписанные или выданные центром сертификации) - общение между компонентами виртуальной инфраструктуры будет вестись посредством TLS с надежным шифрованием. Вопрос сертификатов тут - это всего лишь вопрос доверия: какому объекту, выпустившему сертификат, вы доверяете - это и есть Центр сертификации (он же Certificate Authority, CA).

Многие крупные компании, имеющие определенный вес (например, Microsoft) сами являются Центрами сертификации, а некоторые компании используют службы Microsoft Active Directory Certificate Services, чтобы встроить собственные CA в операционную систему и браузеры (импортируют корневые сертификаты), чтобы "научить" их доверять этим CA.

2. В VMware vSphere сертификаты используются повсеместно.

Как правило, они используются для трех целей:

• Сертификаты серверов ESXi, которые выпускаются для управляющих интерфейсов на всех хост-серверах.
• "Машинные" сертификаты SSL для защиты консолей, с которыми работает человек - веб-консоль vSphere Client, страница логина SSO или Platform Service Controllers (PSCs).
• "Solution"-сертификаты, используемые для защиты коммуникаций со сторонними к платформе vSphere продуктам, таким как vRealize Operations Manager, vSphere Replication и другим.

Полный список компонентов, где vSphere использует сертификаты, приведен вот тут.

3. vSphere имеет собственный Центр сертификации.

Платформа vSphere из коробки поставляется с собственным CA, который используется для коммуникации между компонентами. Называется он VMware Certificate Authority (VMCA) и полностью поддерживается для vSphere как с внешним PSC, так и для vCenter Server Appliance (vCSA) со встроенным PSC.

Как только вы добавляете хост ESXi в окружение vCenter, то VMCA, работающий на уровне vCenter, выпускает новый сертификат на этот ESXi и добавляет его в хранилище сертификатов. Такая же штука происходит, когда вы настраиваете интеграцию, например, с решениями vRealize Operations Manager или VMware AppDefense.

Надо понимать, что CA от VMware - это всего лишь решение для защищенной коммуникации между серверами, которое поставляется из коробки. Ваше право - доверять этой модели или нет.

4. Есть 4 способа внедрить инфраструктуру сертификатов на платформе vSphere.

Вот они:

• Использовать самоподписанные сертификаты VMCA. Вы можете просто скачать корневые сертификаты с веб-консоли vCenter, импортировать их в операционную систему клиентских машин. В этом случае при доступе к веб-консоли, например, vSphere Client у вас будет отображаться зеленый замочек.
• VMCA можно сделать подчиненным или промежуточным (subordinate/ intermediate) центром сертификации, поставив его посередине между CA и конечными хостами, что даст дополнительный уровень сложности и повысит вероятность ошибки в настройке. VMware не рекомендует так делать.
• Отключить VMCA и использовать собственные сертификаты для любых коммуникаций. Ваш ответственный за сертификаты должен нагенерировать запросы Certificate Signing Requests (CSR) для всех компонентов. Эти CSR-запросы вы отсылаете с CA, которому вы доверяете, получаете их подписанными, после чего устанавливаете их в ручном режиме. Это отнимает время и чревато ошибками. 
• Использовать гибридный подход - для хостов ESXi в их коммуникации с vCenter использовать самоподписанные VMCA сертификаты, а для веб-консолей vSphere Client и прочих использовать перевыпущенные сертификаты, которые надо установить на сервере vCenter и хостах, с которых будет управляться инфраструктура через браузер (тогда в нем появится зеленый замочек). Это самый рекомендуемый VMware вариант использования сертификатов.

5. Enterprise-сертификаты - тоже самоподписанные.

Подумайте - самоподписанными являются не только сертификаты VMCA, но и ваши корпоративные сертификаты. Если вы выпускаете эти сертификаты только на уровне своей компании, то у вас 2 точки потенциального недоверия - сторона, выпустившая сертификаты у вас в компании, а также, собственно, сам VMCA. Такая схема создает дополнительный уровень сложности администрирования, а также нарушения безопасности.

6. Не создавайте промежуточный Центр сертификации.

Если вы создаете intermediate CA (он же subordinate CA) для VMCA, превращая его в посредника, вы создаете потенциальную опасность для виртуальной инфраструктуры - если кто-то получает доступ к корпоративному центру сертификации и его парам ключей, то он может навыпускать любых сертификатов от имени VMCA и перехватывать потом любые коммуникации.

7. Можно изменять информацию для самоподписанных сертификатов CA.

С помощью утилиты  Certificate Manager utility вы можете сгенерировать новый VMCA с необходимой информацией о вашей организации внутри него. Эта утилита перевыпустит все сертификаты и заменит их на всех хостах виртуальной инфраструктуры. Это хорошая опция для гибридной модели. Кстати, вы можете менять даты устаревания сертификатов, если дефолтные вас не устраивают.

8. Тестируйте инфраструктуру сертификатов перед внедрением.

Вы можете развернуть виртуальную инфраструктуру и провести все эксперименты с сертификатами в виртуальной среде, где вы можете использовать виртуальные (nested) серверы ESXi. Приятная штука в том, что вы можете создавать снапшоты виртуальных машин, а значит в случае чего - быстро откатитесь на рабочий вариант. Еще одна среда для экспериментов - это облачная инфраструктура VMware Hands-on Labs, где можно безопасно ставить любые эксперименты.

Попробуйте также новую vSphere 6.7 Lightning Lab.

9. Делайте бэкапы своей инфраструктуры.

Делайте резервную копию вашего vCenter и PSC на уровне файлов через веб-консоль VAMI. Также утилитой Certificate Manager можно скопировать старый набор сертификатов перед развертыванием новых (но только один набор сертификатов, учитывайте это). Также эта процедура полностью поддерживается со стороны VMware Global Support Services.

10. Понимайте, зачем вы заморачиваетесь с заменой сертификатов.

Ответьте для себя на несколько вопросов:

• Стоит ли иконка зеленого замочка в браузере всех этих заморочек?
• Нужно ли всем видеть этот замочек или только команде администрирования vSphere?
• Почему вы доверяете vCenter для управления всем в виртуальной инфраструктуре, но не доверяете VMCA?
• В чем отличие самоподисанного сертификата вашего предприятия от самоподписанного сертификата VMCA?
• Действительно ли комплаенс требует от вас кастомных CA-сертификатов?
• Какова будет цена процедур по замене сертификатов в инфраструктуре vSphere во времени и деньгах?
• Увеличивает или уменьшает риск итоговое решение и почему конкретно?

Дополнительные ресурсы

• Живое кликабельное демо (feature walkthrough) о пошаговой настройке гибридного режима работы с сертификатами.
• Пост блога Adam Eckerle о гибридном режиме.
• Скачать корневые сертификаты VMCA root CA можно с главной страницы vCenter. В vSphere 6.7 ссылка расположена внизу справа.
• Wildcard-сертификаты не поддерживаются в среде vSphere.
• О сертификатах можно почитать в отличной документации по vSphere.
• Статьи Вильяма Лама о вложенных серверах ESXi.
• Статья о безотзывных сертификатах Active Directory Certificate Services.
• Как работает инфраструктура открытых ключей (пост EFF).
• При замене сертификатов подготовьте для тестирования несколько браузеров и научитесь быстро чистить в них кэш.
• Мы писали об утилите SDDC Certificate Tool, которая позволит вам просто заменить сертификаты во всем окружении vSphere.
• Архитектура VMware Cloud Foundation имеет средства по автоматизации управления жизненным циклом сертификатов.

Дункан написал полезный пост о том, влияет ли установка лимитов по вводу-выводу в кластере VMware vSAN (I/O Limit) на производительность операций ресинхронизации кластера и перемещение машин между хранилищами Storage vMotion (SVMotion).

Вопрос этот важен, так как многие пользуются лимитами для виртуальных машин на уровне хранилищ vSAN, но не хотят, чтобы в случае сбоя ресинхронизация кластера или перемещение машин происходили с ограничениями, которые могут увеличить время восстановления в разы.

Ответ тут прост - нет, не влияет. Лимиты устанавливаются на уровне гостевой системы для VMDK-дисков виртуальных машин и сопутствующих объектов (например, снапшоты, своп и т.п.), поэтому операции, которые проводятся извне со стороны платформы, в этом не участвуют.

Таким образом, лимиты для виртуальных машин можно ставить без ограничений и не заботиться о том, что это повлияет на время восстановление кластера и отдельных ВМ в случае сбоя. Операции SVMotion также затронуты не будут.

Июнь оказался весьма богат на новые релизы на сайте проекта VMware Labs - недавно мы писали про обновление Horizon DaaS Migration Tool 2.1 для миграции облака DaaS, новое средство Flowgate для агрегации метрик, обновления HCIBench и USB Network Native Driver for ESXi.

Но на этом релизы не остановились - на днях VMware выпустила обновленную утилиту IOBlazer, которая позволяет сгенерировать нагрузку на хранилища с любых платформ - Linux, Windows и OSX. Утилита была выпущена еще в 2011 году, но с тех пор не дорабатывалась, а вот на днях мы увидели ее версию 1.01.

Основная фича утилиты - возможность тонко кастомизировать параметры нагрузки на хранилище изнутри виртуальной машины, такие как размер IO и паттерн нагрузки, пакетирование (объем исходящих операций ввода-вывода), временные промежутки между пакетами, микс трафика чтения/записи, буфферизованные или прямые операции ввода-вывода и многое другое.

IOBlazer также может "проигрывать" записанные логи VSCSI, которые были получены за счет использования утилиты vscsiStats. В качестве метрик производительности можно получить пропускную способность в IOPS и в мегабайтах в секунду, а также задержки ввода-вывода (IO latency). Это дает возможность IOBlazer сгенерировать синтетическую нагрузку на диск виртуальной машины, которая соответствует реальной нагрузке, с возможностью ее повторения в любой момент.

IOBlazer вырос из минималистичного эмулятора MS SQL Server, который бы сфокусирован на эмуляции только нагрузки по вводу-выводу. Ранее утилита имела очень ограниченные возможности по генерации нагрузки по модели MS SQL Server IO (Асинхронность, небуфферизованные IO, параметры Gather/Scatter), теперь же все стало существенно лучше. Но 2 ограничения все еще остаются:

1. Выравнивание доступа к памяти по 4 КБ (страница памяти).

2. Выравнивание операций доступа к диску по 512 байт (дисовый сектор).

Утилиту не надо устанавливать - она запускается из дистрибутива. Инструкции можно найти в файле README. Скачать IOBlazer 1.01 можно по этой ссылке. В комплекте также идет исходник на C, который вы можете собрать самостоятельно.

На сайте проекта VMware Labs появилась еще одна утилита - Horizon DaaS Migration Tool 2.1. Она позволяет смигрировать ранние версии Horizon DaaS (6.1.5, 6.1.6, 7.0.0) на самую последнюю версию 8.0.0. Напомним, что Horizon DaaS - это продукт купленной компании Desktone.

Почему надо мигрировать на последнюю версию DaaS:

• VMware Horizon DaaS 6.1.5, 6.1.6 скоро перестанет поддерживаться.
• Клиенты на версии VMware Horizon DaaS 8.0.0 смогут обновиться на новые версии, для которых будут выходить новые фичи и апгрейд функциональности и безопасности.

Для миграции поддерживаются сценарии VMware Horizon DaaS 6.1.x и 7.0.0 на версию 8.0.0. Между тем, не поддерживаются следующие сценарии:

• При миграции не поддерживаются Floating Desktops, поэтому их надо пересоздавать отдельно путем миграции золотых образов, после чего надо пересоздать пулы десктопов.
• Миграция хостов RDSH и приложений. Их нужно мигрировать так же, как и Floating Desktops.
• Функциональность Multi Data Center пока не поддерживается в Horizon DaaS 8.0.0.
• Несколько Multi Desktop Managers не поддерживается для одного клиента.

Последние две возможности скоро будут доступны в обновленной версии Horizon DaaS. Скачать VMware Horizon DaaS Migration Tool 2.1 и инструкции по миграции можно по этой ссылке.

На VMware Labs еще одно обновление - инженеры VMware выпустили продукт Flowgate, который представляет собой средство агрегации данных из различных источников. Это middleware, которое позволяет провести агрегацию данных систем инвентаризации датацентров DCIM / CMDB и далее передать их в системы управления задачами инфраструктуры (например, vRealize Operations).

В данном решении есть встроенный адаптер для интеграции со следующими системами DCIM и CMDB, которые хранят данные о составе, размещении и конфигурации ИТ-инфраструктуры:

• Nlyte
• PowerIQ
• Infoblox
• Labsdb
• IBIS (еще не полностью)
• Pulse IoT Center (еще не полностью)

С точки зрения интеграции с этими системами, все происходит в графическом интерфейсе в несколько кликов. Также внутри Flowgate есть встроенный механизм управления пользователями и ролями RBAC (Role Based Access Control) с большим выбором привилегий для конфигурации.

Надо отметить, что архитектура Flowgate открыта для интеграции с любыми другими сторонними системами. С помощью RESTFul API можно запрашивать любые данные и далее визуализовывать их уже как угодно, также все задачи управления решением доступны через API.

С точки зрения систем управления задачами ИТ-инфраструктуры, где собранные метрики визуализируются, на данный момент реализована интеграция с vCenter Server и vRealise Operation Manager, но скоро будет добавлена поддержка и других систем.

Более подробно о том, как работает Flowgate, можно узнать из следующего видео, созданного авторами Flowgate:

Для машины с Flowgate на борту, осуществляющей агрегацию данных, потребуется минимум 4 vCPU, 8 ГБ памяти и 60 ГБ диска, но рекомендуется выделить 8 vCPU и 16 ГБ RAM соответственно.

Скачать Flowgate можно по этой ссылке.

Довольно давно VMware не обновляла свой универсальный фреймворк для управления виртуальной инфраструктурой, но вот на днях вышел VMware PowerCLI 11.3. Напомним, что прошлая версия пакета VMware PowerCLI 11.2 вышла в марте этого года.

Давайте посмотрим, что нового появилось в PowerCLI 11.3:

1. Добавлено 22 новых командлета для управления компонентами HCX и SPBM (политики хранилищ).

Их поддержка уже была в версии 11.2, но теперь она расширилась. Для HCX теперь доступны следующие командлеты:

• Get/New/Remove/Set-HCXComputeProfile
• Get-HCXInventoryCompute
• Get-HCXInventoryDatastore
• Get-HCXInventoryDVS
• Get-HCXInventoryNetwork
• Get-HCXNetworkBacking
• Get/New/Remove/Set-HCXNetworkProfile
• Get/New/Remove/Set-HCXServiceMesh
• Get-HCXStorageProfile
• New-HCXComputeProfileDVS
• New-HCXComputeProfileNetwork
• New-HCXServiceMeshDVS

В плане поддержки SPBM, появился новый командлет Get-SpbmView, который предоставляет прямой доступ к API механизма управления политиками хранилищ. В примере ниже выведен список доступных сервисов и взаимодействие с сервисом Replication Manager для получения набора доступных методов:

Также теперь командлеты Get/Set-SpbmEntityConfiguration могут просматривать или изменять политики хранилищ SPBM для датасторов. Вот пример работ командлета для вывода параметров политики датастора:

2. Поддержка vSphere 6.7 Update 2 в модуле VMware.VIM.

Теперь последняя версия платформы vSphere полностью поддерживается для управления через этот модуль.

3. Поддержка opaque networks в командлете Get-VirtualNetwork.

Эти сети появляются как результат работы с логическими коммутаторами в решении NSX-T. В версии PowerCLI 11.2 управление такими сетями было доступно только через прямой API, а сейчас можно управлять ими с помощью высокоуровневого командлета:

Для получения дополнительной информации о таких сетях обратитесь к статье Configuring VMs with Opaque Networks.

4. Добавлена возможность создания дополнительных типов сетевых адаптеров.

Здесь были добавлены адаптеры SriovEthernetCard и Vmxnet3Vrdma, а также появились параметры PhysicalFunction и DeviceProtocol.

5. Поддержка высокоуровнего преобразования мгновенных клонов (instant clones) в обычные ВМ.

Начиная с vSphere 6.7, мгновенные клоны (instant clones) стали доступны для пользователей в производственной среде, но управлять ими можно было только через API. Теперь же с помощью PowerCLI 11.3 можно использовать командлет Set-VM совместно с параметром PromoteDisks, что даст возможность преобразовать машину instant clone в самостоятельную ВМ, которая больше не зависит от родительской. 

6. Обновлена обработка статусов кластера для свойства SpbmEnabled.

Теперь для датастора в кластере не показывается статус SpbmEnabled, так как он всегда включен и не может быть отключен пользователем.

7. Обновленная обработка пакетного режима привязки тэгов.

Теперь привязка тэгов vSphere tags с помощью командлета New-TagAssignment идет на стороне сервера в пакетном режиме, что дает существенный прирост производительности (от 12 до 18 раз):

О производительности этого процесса есть также интересная статья "Writing Performant Tagging Code".

Для получения более полной информации о нововведениях обратитесь к документу VMware PowerCLI Change Log. О самих возможностях фреймворка прекрасно рассказано в документе VMware PowerCLI 11.3.0 User’s Guide. Ну а о том, как работает тот или иной командлет, можно узнать в VMware PowerCLI 11.3.0 Cmdlet Reference.

Как обычно, обновление на версию PowerCLI 11.3 надо делать помощью командлета Update-Module:

Коллеги из Veeam Software попросили помочь в поиске человека, который будет заниматься контент-маркетингом в сфере защиты данных и обеспечения доступности виртуальных датацентров. Надо писать тексты, хорошие заголовки и брифы, а также говорить на английском (и, желательно, испанском) языке.

Veeam представлять не требуется - это один из лидеров петербургского (а сейчас уже международного) ИТ-рынка, компания которая стоит не менее 5 миллиардов долларов. Внутри отличная корпоративная атмосфера (просто потому, что стараются брать на работу адекватных людей) и возможности релокации по всему миру (если вам такое интересно). Можно переехать в Чехию, в Америку, в Бухарест, да и вообще много куда.

Ссылка на вакансию - https://careers.veeam.ru/vacancies/it/writer-content-marketing-743999689524636

Собственно, само описание:

Writer, Content Marketing

Veeam Software is a global leader in intellectual data management based in more than 30 countries that serves 343,000+ customers all over the world.

Our clients are big and midsize business from different industries.  We help 82% Fortune 500 companies to evolve the way they manage data and to ensure it’s available across any application and across any cloud infrastructure.
We are trusted by: L’Oreal, PwC, Volvo, Gatwick, Scania and many more.

In a partnership with VMware и Microsoft we help business to improve.

• Английский

•  Create short texts, product descriptions, blog posts, white papers about Veeam solutions and data management industry in general - topics might include virtualization, data protection for both physical and virtual environments, cloud data management, server networking, data center infrastructure trends etc - with purpose of helping to drive organic and paid traffic to Veeam sites and raise awareness about Veeam solutions and thought leadership. 
• Publish content via WordPress on Veeam blogs or coordinate content publishing on 3rd party platforms.  
• Collaborate with external and internal subject matter experts (evangelists, bloggers, engineers, developers, analytics, IT administrators) on content topic development and content creation. 
• Collaborate with multiple teams across regions/departments to ensure aligned content production and promotion: product marketing, campaign management, digital advertisement, email marketing, SEO, localization, creatives, web-development etc. 
• Initiate and drive projects with creative and web-development teams to ensure effective content placement on Veeam and 3rd party web sites (mainly Veeam blog UX). 
• Use Google Analytics, MOZ and similar digital analytical tools to perform regular reporting on content activities results. 
• Maintain content publishing schedule for particular audiences/regions. 
• Work with tracking, planning and CRM systems for tasks management and analytics.

• Proven written and oral communication English and Spanish language skills, including business communications. 
• In-bound and out-bound digital marketing understanding. 
• Ability to learn quickly. 
• Strong interpersonal, writing, and verbal skills. 
• Must be able to work effectively both as a team member and independently. 
• Demonstrate ability to prioritize, multi-task, and work with minimal supervision in a team environment. 
• Strong organization skills with emphasis on being conscientious and detail-oriented. 
• Strong computer skills and proficiency in Word, Excel, Outlook and PowerPoint. 
• Technical understanding of data protection industry and virtualization principles. 
• Technical background (degree or work experience as network/support engineer or similar) and/or work experience in Digital Marketing is a strong plus. 
• Working knowledge of computer software such as VMware, Windows Server/Hyper-V or similar is a strong plus. 
• Experience in Google Analytics is a strong plus. 
• Basic understanding and/or experience of PPC, SEO, analytics and web-development is a strong plus.

• Work in a stable, dynamic company
• Modern energetic multinational working environment
• Interesting people, an excellent team of professionals
• Extensive opportunities for professional growth and career
• Flexible work schedule (work on European time)
• Employment according to the Labor Code of the Russian Federation, “white” salary
• An extended medical insurance policy
• Opportunity to join the Veeam footbal/lvolleyball team
• Partial compensation of costs on fitness
• Annual leave 28 days

Откликнуться на вакансию можно по этой ссылке.

Как знают почти все администраторы платформы VMware vSphere, для кластеров VMware HA/DRS есть такой режим работы, как Enhanced vMotion Compatibility (EVC). Нужен он для того, чтобы настроить презентацию инструкций процессора (CPU) хостами ESXi так, чтобы они в рамках кластера соответствовали одному базовому уровню (то есть все функции процессоров приводятся к минимальному уровню с набором инструкций, которые гарантированно есть на всех хостах).

Ввели режим EVC еще очень давно, чтобы поддерживать кластеры VMware vSphere, где стоят хосты с процессорами разных поколений. Эта ситуация случается довольно часто, так как клиенты VMware строят, например, кластер из 8 хостов, а потом докупают еще 4 через год-два. Понятно, что процессоры уже получаются другие, что дает mixed-окружение, где по-прежнему надо перемещать машины между хостами средствами vMotion. И если набор презентуемых инструкций CPU будет разный - двигать машины между хостами будет проблематично.

EVC маскирует инструкции CPU, которые есть не на всех хостах, от гостевых ОС виртуальных машин средствами интерфейса CPUID, который можно назвать "API для CPU". В статье VMware KB 1005764 можно почитать о том, как в кластере EVC происходит работа с базовыми уровнями CPU, а также о том, какие режимы для каких процессоров используются.

Надо отметить, что согласно опросам VMware, режим кластера EVC используют более 80% пользователей:

В VMware vSphere 6.7 появились механизмы Cross-Cloud Cold и Hot Migration, которые позволяют переносить нагрузки в онлайн и офлайн режиме между облаками и онпремизной инфраструктурой.

Когда это происходит, виртуальной машине приходится перемещаться между хостами с разными наборами инструкций процессора. Поэтому, в связи с распространением распределенных облачных инфраструктур, в vSphere появилась технология Per-VM EVC, которая позволяет подготовить виртуальную машину к миграции на совершенно другое оборудование.

По умолчанию, при перемещении машины между кластерами она теряет свою конфигурацию EVC, но в конфигурации ВМ можно настроить необходимый базовый уровень EVC, чтобы он был привязан к машине и переезжал вместе с ней между кластерами:

Обратите внимание, что Per-VM EVC доступна только, начиная с vSphere 6.7 и версии виртуального железа Hardware Version 14. Эта конфигурация сохраняется в vmx-файле (потому и переезжает вместе с машиной) и выглядит следующим образом:

featMask.vm.cpuid.Intel = “Val:1”
featMask.vm.cpuid.FAMILY = “Val:6”
featMask.vm.cpuid.MODEL = “Val:0x4f”
featMask.vm.cpuid.STEPPING = “Val:0”
featMask.vm.cpuid.NUMLEVELS = “Val:0xd”

Некоторые пользователи не включают EVC, так как покупают унифицированное оборудование, но VMware рекомендует включать EVC в кластерах со старта, так как, во-первых, никто не знает, какое оборудование будет докупаться в будущем, а, во-вторых, так будет легче обеспечивать миграцию виртуальных машин между облачными инфраструктурами.

Основная причина, по которой не включают EVC - это боязнь того, что поскольку машины не будут использовать весь набор инструкций CPU (особенно самых последних), то это даст снижение производительности. Поэтому VMware написала целый документ "Impact of Enhanced vMotion Compatibility on Application Performance", где пытается доказать, что это не сильно влияет на производительность. Вот, например, производительность Oracle на выставленных базовых уровнях для разных поколений процессоров (в документе есть еще много интересных графиков):

Чтобы включить EVC на базе виртуальной машины, нужно ее выключить, после чего настроить нужный базовый уровень. Для автоматизации этого процесса лучше использовать PowerCLI, а сама процедура отлично описана в статье "Configuring Per-VM EVC with PowerCLI".

Для того, чтобы выяснить, какие базовые уровни EVC выставлены для виртуальных машин в кластере, можно использовать следующий сценарий PowerCLI:

Get-VM | Select Name,HardwareVersion,
@{Name='VM_EVC_Mode';Expression={$_.ExtensionData.Runtime.MinRequiredEVCModeKey}},
@{Name='Cluster_Name';Expression={$_.VMHost.Parent}},
@{Name='Cluster_EVC_Mode';Expression={$_.VMHost.Parent.EVCMode}} | ft

Это даст примерно следующий результат (надо помнить, что отчет будет сгенерирован только для VM hardware version 14 и позднее):

В примере выше одна машина отличается от базового уровня хостов, но в данном случае это поддерживаемая конфигурация. Проблемы начинаются, когда машина использует более высокий базовый уровень CPU, чем его поддерживает хост ESXi. В этом случае при миграции vMotion пользователь получит ошибку:

Понять максимально поддерживаемый режим EVC на хосте можно с помощью команды:

Get-VMHost | Select-Object Name,ProcessorType,MaxEVCMode

В итоге вы получите примерно такой отчет:

В целом тут совет такой - включайте режим Enhanced vMotion Compatibility (EVC) в кластерах и для виртуальных машин VMware vSphere сейчас, чтобы не столкнуться с неожиданными проблемами в будущем.

На сайте VMware Labs обновилась утилита HCIBench до версии 2.1.

Напомним, что о версии HCIBench 2.0 мы писали вот тут, а здесь мы рассматривали использование этой утилиты для замеров производительности кластеров VMware vSAN. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.

Проект HCIbecnh ("Hyper-converged Infrastructure Benchmark") является оберткой для известного open source теста VDbench, он позволяет организовать автоматизированное тестирование гиперконвергентного кластера (HCI-кластера). Гиперконвергентный кластер - это когда все его вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

Целью такого тестирования может быть, например, необходимость убедиться, что развернутая инфраструктура обеспечивает достаточную производительность для планируемой на нее нагрузки.

Что нового появилось в HCIBench 2.1:

• Интерфейс переключили на темную тему.
• Переработанная технология подготовки VMDK, которая теперь работает гораздо быстрее за счет использования рандомизации на дедуплицированных хранилищах.
• Добавлена возможность обновления процесса подготовки VMDK.
• Добавлена проверка портов базы данных Graphite в процесс превалидации.
• Пароли vCenter и хостов ESXi затемняются при сохранении
• Добавлена кнопка удаления гостевой ВМ ("Delete Guest VM").
• Пофикшены проблемы с дисплеями для Grafana.
• Пофикшена проблема с пустыми результатами при отработки модели нагрузки FIO (Flexible I/O).
• Множество мелких исправлений ошибок.

Скачать HCIBench 2.1 можно по этой ссылке. Документация пока доступна только для версии 2.0.

На сайте проекта VMware Labs появилось очередное обновление - стала доступна новая версия средства USB Network Native Driver for ESXi до версии 1.1. Напомним, что ранее мы писали о нем вот тут. Это нативный драйвер для сетевых адаптеров серверов, которые подключаются через USB-порт.

Такой адаптер можно использовать, когда вам необходимо, например, подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. В каких-то еще случаях подключение такого адаптера может помочь, чтобы получить еще одно сетевое соединение без необходимости перезагружать сервер (и так же просто отключить его).

Новая версия драйвера содержит поддержку девяти новых устройств USB NIC, включая девайсы USB 2.0 RTL8152 & TPLINK. Полный список поддерживаемых устройств теперь таков:

Помимо этого, в драйвер также была добавлена поддержка Jumbo Frames (размером до 4K) для устройств RTL8153 и AX88179.

Для установки драйвера нужно развернуть на ESXi 6.5 или 6.7 один из двух VIB-пакетов для соответствующей версии:

• ESXi670-VMKUSB-NIC-FLING-20124247-offline_bundle-11613968
• ESXi650-VMKUSB-NIC-FLING-20123976-offline_bundle-11613344

Делается это следующей командой:

esxcli software vib install -d /path/to/the/offline/bundle

После установки нужно перезагрузить хост VMware ESXi, после чего устройство USB NIC будет автоматически смонтировано как, например, vusb0.

Скачать USB Network Native Driver for ESXi можно по этой ссылке.

Очень часто администраторы платформы VMware vSphere задаются следующими вопросами о версиях продукта vCenter: какая разница между обновлением vCenter (он же update) и патчем (patch)? в чем отличие апгрейда (upgrade) и миграции (migration)? почему некоторые версии vCenter нумеруются как-то отдельно? Попробуем дать ответы на эти вопросы ниже, используя материал вот этой статьи в блоге VMware.

Первое, что нужно понять - это нумерация версий vCenter. Она подразумевает 2 компонента - номер версии (например, vCenter 6.7 Update 2a) и номер билда (например, 13643870):

Номер версии имеет также и цифровое обозначение. Если вы зайдете в интерфейс VMware Appliance Management Interface (VAMI), то увидите там номер билда (13643870), а также полный номер версии (6.7.0.31000):

Если же вы зайдете в vSphere Client и перейдете там на вкладку Summary для вашего сервера vCenter (в данном случае vCenter Server Appliance, vCSA), то увидите там версию 6.7.0:

В данном случае в поле Build указан номер билда клиента vSphere Client (13639324), и не стоит его путать с номером билда самого vCenter. Все это как-то более-менее соотносится между собой (VAMI дает более полную информацию о цифровом номере версии).

Теперь, чтобы сложить все это в единую картину и соотнести с датой релиза конкретной версии vCenter, существует статья базы знаний KB 2143838, где есть полезная табличка:

Обратите внимание на последнюю колонку - Client/MOB/vpxd.log. Это версия клиента vSphere Client, и именно она появится в лог-файле vpxd.log, поэтому не стоит удивляться, что она отличается от номера билда vCenter.

Теперь перейдем к апдейтам и патчам. vCenter Server Update - это полноценное обновление платформы, которое может включать в себя новый функционал, исправления ошибок или доработки существующей функциональности. Выходит апдейт довольно редко и имеет свое строковое наименование (например, vCenter 6.7 Update 2a). Для апдейта всегда выпускается документ Release Notes, и его можно скачать через my.vmware.com.

Патч - это постоянно выпускаемое небольшое обновление для vCenter, которое поддерживает уровень безопасности, закрывает критические уязвимости, исправляет фатальные ошибки и т.п. Он может относиться к вспомогательным компонентам vCSA, например, Photon OS, базе данных Postgres DB или фреймворку Java.

Для патча нет выделенного документа Reelase Notes, но информация о нововведениях доступна в VMware vCenter Server Appliance Photon OS Security Patches. Патчи нельзя скачать через my.vmware.com, но они загружаются через VMware Patch Portal. Само собой, патчи включаются в апдейты, выпускаемые на какой-то момент времени. Патчи накатываются в рамках одного цифрового обновления. То есть 6.7 Update 1 не патчится напрямую на 6.7 Update 2b, сначала надо накатить апдейт 6.7 Update 2a, а затем уже пропатчиться на 6.7 Update 2b.

Также на VMware Patch Portal вы можете найти ISO-образы vCenter Server, но их не надо использовать для новых развертываний, они нужны только для восстановления вашего vCenter Server Appliance, если вы используете резервное копирование на уровне файлов.

Теперь перейдем к разнице между апгрейдом и миграцией. Апгрейд - это обновление мажорной версии сервера vCenter одного типа развертывания (например, вы делаете апгрейд vCenter Server Appliance 6.5 на vCenter Server Appliance 6.7). Миграция - это когда вы меняете тип развертывания vCenter, переходя, например, с Windows-платформы на Linux (к примеру, vCenter Server 6.5 for Windows мигрируете на vCenter Server Appliance 6.7).

Если вы обновляете vCSA 6.5 на 6.7, то апгрейд идет как бы ненастоящий - развертывается новый виртуальный модуль vCSA 6.7, и на него переезжают все настройки (FQDN, IP, сертификаты и UUID), а также содержимое базы данных vCSA 6.5.

Также надо упомянуть и back-in-time upgrade - это когда вы хотите обновить, например, vSphere 6.5 Update 2d на vSphere 6.7 Update 1. Прямое обновление тут не поддерживается, так как  Update 2d для версии 6.5 вышел позднее, чем Update 1 для версии 6.7. То есть Update 2d содержит код, которого нет в Update 1, а значит это может вызвать потенциальные конфликты.

Поэтому для каждой новой версии vCenter выпускается раздел Upgrade Notes for this Release, где можно найти информацию о возможности апгрейда:

На сайте проекта VMware Labs появилось очередное обновление - Workspace ONE UEM SCIM Adapter. С помощью этого средства администратор получает возможности управления пользователями, группами и правами доступа SCIM в инфраструктуре решения Workspace ONE UEM.

Это средство представляет собой middleware, которое транслирует интерфейс System for Cross-Domain Identity Management (SCIM) во фреймворк CRUD REST, который может интерпретировать средство Workspace ONE UEM. Эта возможность позволяет Workspace ONE UEM синхронизировать облачные сервисы идентификации (пользователи/группы/назначения прав) без необходимости дополнительной интеграции LDAP (service to service model). Такими примерами являются решения Azure AD, Okta и Sailpoint.

Примеры развертывания данного средства можно посмотреть в следующих статьях:

• WS1 UEM SCIM Adapter
• Install Workspace ONE UEM SCIM Adapter on Photon OS

Документация по Workspace ONE UEM SCIM Adapter доступна по этой ссылке. Скачать сам адаптер можно вот тут.

У средства обновления хостов VMware vSphere Update Manager (VUM) есть полезный механизм проверок Pre-Check Remediation Report, который выполняет предварительную проверку условий для обновления хостов ESXi, чтобы этот процесс не прервался уже после его начала. Эти условия очень просты, но иногда позволяют сэкономить массу времени, особенно в большой инфраструктуре VMware vSphere.

Чтобы запустить эти проверки, надо выбрать нужный вам кластер и нажать кнопку Pre-Check Remediation:

После того, как вы запустите предпроверку Update Manager, вы получите отчет с предупреждениями о фактах, мешающих дальнейшим обновлениям:

Отчет Pre-Check Remediation Report для кластера может содержать следующие пункты:

Отчет Pre-Check Remediation Report для виртуальных машин может содержать следующее:

Компания VMware опубликовала уведомление VMSA-2019-0009 для пакета VMware Tools, который содержит уязвимость, позволяющую непривилегированному пользователю читать данные из гостевой ВМ, а также негативно влиять на ее гостевую ОС. Уязвимости подвержены версии VMware Tools ниже 10.3.10.

В качестве примера использования такой уязвимости можно привести Windows-машины, где включены службы Microsoft Remote Desktop Services. Также риску подвержены службы Microsoft SQL Server или IIS, использующие сервисные аккаунты.

Сначала надо вывести все ВМ, имеющие VMware Tools версии ниже 10.3.10 с помощью следующей команды PowerCLI:

Get-VM | Where-Object {$_.Guest.ToolsVersion -lt ‘10.3.10’} | Sort-Object Name | Format-Table

Вот такая команда выдаст все Windows-машины с VMware Tools ниже, чем 10.3.10:

Get-VM | Where-Object {$_.Guest.ToolsVersion -lt ‘10.3.10’ -and $_.Guest.GuestFamily -eq ‘windowsGuest’} | Sort-Object Name | Format-Table

Проверить версию VMware Tools можно и самостоятельно в VMware vSphere Client:

Помните, что VMware 6.7 Update 2a идет с версией VMware Tools 10.3.5. Надо отметить, что гостевые ОС Linux не подвержены уязвимости, поэтому не пугайтесь, что open-vm-tools имеют только версию 10.3.5.

Последнюю же версию пакета тулзов можно скачать по этой ссылке: https://www.vmware.com/go/tools.

Если вы хотите обновить VMware Tools через офлайн-бандл, то скачайте "VMware Tools Offline VIB Bundle", после чего можно использовать vSphere Update Manager (VUM) для развертывания установщиков пакета на хостах ESXi без простоя. После этого машины должны в течение 5 минут схватить новую версию тулзов (таков период обновления информации об актуальной версии пакета). Установленная версия VMware Tools также проверяется и при vMotion, а, кроме того, и при операциях с питанием ВМ (включение/выключение).

В большой инфраструктуре вы можете настроить централизованный репозиторий VMware Tools для использования в качестве источника для многих хостов ESXi.

Обновление VMware Tools можно инициировать через PowerCLI с помощью следующего командлета:

Get-VM | Where-Object {$_.ExtensionData.Guest.ToolsVersionStatus -eq "guestToolsNeedUpgrade" -and $_.PowerState -eq "PoweredOn"} | Get-VMGuest | Where-Object {$_.GuestFamily -eq "windowsGuest" } | Update-Tools -NoReboot -RunAsync

Помните, что при апгрейде VMware Tools вам может потребоваться перезагрузка виртуальных машин и их гостевых ОС. Также вы можете использовать приведенный выше сценарий для нескольких ВМ в одной папке:

Get-VM “TEST-VM-02” | Where-Object…
Get-Folder “Test VMs - Snapshotted" | Get-VM | Where-Object…

Через vSphere Client тулзы также прекрасно обновляются:

Если вы используете опцию "Automatic Upgrade", то машина будет обновлена автоматически (без взаимодействия с гостевой ОС) и, при необходимости, перезагрузится. Также вы можете использовать обновление тулзов без немедленной перезагрузки, применив инструкции, описанные в KB1018377. Надо помнить, что в этом случае до перезагрузки будет работать старая версия VMware Tools, а значит, что до перезагрузки машины уязвимость будет актуальна.

Еще одна опция - настроить обновления тулзов в настройках виртуальной машины:

Иногда администраторы гостевой системы имеют эксклюзивный доступ к ней (например, админы бизнес-критичных баз данных) и контролируют все происходящие в ней события. Для этого надо настроить их взаимодействие с машиной как указано в KB 2007298.

В этом случае они получат нотификацию о новой версии VMware Tools из трея, либо могут проверить наличие обновлений самостоятельно с помощью команд:

• VMwareToolboxCmd.exe –v - проверка установленной версии.
• VMwareToolboxCmd.exe upgrade status - возможность обновления для доступных апгрейдов.
• VMwareToolboxCmd.exe upgrade start - запуск процедуры апгрейда.

В этом случае запустится графический установщик, но не требующий вмешательства пользователя.

Администраторы отказоустойчивых кластеров хранилищ VMware vSAN часто сталкиваются с проблемами производительности, наблюдаемыми в виртуальной среде. Как правило, о таких проблемах администратор узнает двумя путями: либо ему сообщают пользователи, либо он видит алерты, которые генерируются в консоли клиента vSphere Client при превышении определенных пороговых значений.

Так или иначе, администратор должен, прежде всего, выяснить, что проблема низкой производительности приложений проявляет себя именно на уровне гостевой системы. В этом случае VMware предлагает придерживаться следующего рабочего процесса:

Основные моменты траблшутинга по такому воркфлоу рассказаны в документе "Troubleshooting vSAN Performance". Самый очевидный симптом проблем - это задержки (Latency) на уровне гостевой ОС (то есть время, затраченное на выполнение транзакции ввода-вывода), которые приводят к медленной работе приложений.

Задержки измеряются в миллисекундах, и интерпретация их значений зависит от контекста - размер блока ввода-вывода, характер потока (чтение/запись, последовательное/случайное). При этом latency измеряется на некотором сегменте прохождения команд к хранилищу, на каждом из участков которого также возникают свои составляющие задержек. Анализ таких компонентов Storage stack в контексте задержек и поиск узких мест - и есть основная задача администратора, решающего проблемы низкой производительности приложений для пользователей. Многое из этого можно делать с помощью утилиты ESXTOP, о которой мы много писали.

Обратите внимание, что на иллюстрации фреймворка выше, анализ виртуальной инфраструктуры и анализ приложений и их рабочих процессов находится еще до анализа метрик. Это связано с тем, что выбор метрик, на которые стоит обратить внимание в среде VMware vSAN, зависит от характера происходящих проблем.

После того, как администратор выяснил основные признаки проблемы и локализовал ее на уровне приложений, можно приступать к анализу метрик. Алгоритм действий приведен в документе "Troubleshooting vSAN Performance":

Тут рекомендуется делать следующее:

• Шаг 1 - просматриваем метрики в гостевой ОС проблемной ВМ, чтобы убедиться, что проблемы с производительностью хранилища ощущаются на уровне приложений.
• Шаг 2 - просматриваем метрики на уровне кластера vSAN, чтобы в целом понять масштаб проблемы - нет ли других аномалий в кластере. Это позволяет идентифицировать потенциальные "наводки" от других компонентов виртуальной инфраструктуры.
• Шаг 3 - просматриваем метрики на уровне хоста ESXi, чтобы соотнести метрики внутри гостевой ОС и всего хоста в целом с точки зрения latency.
• Шаг 4 - смотрим на хосте метрики дисковой группы, чтобы найти источник повышенной latency.
• Шаг 5 - если не нашли проблему на шаге 4, то смотрим на сеть хоста и метрики VMkernel, чтобы убедиться, что сеть функционирует штатно.

То есть смысл прост - если что-то тормозит в кластере VMware vSAN, то это либо дисковая подсистема, либо сетевая инфраструктура. Ну и главное - правильно идентифицировать хост/хосты ESXi, где находятся компоненты виртуальной машины.

И еще одна важная рекомендация - при траблшутинге старайтесь не менять несколько настроек одновременно, чтобы решить проблему. Во-первых, вы не сможете понять, какая из настроек или их комбинация дала правильный эффект, а, во-вторых, вы не сразу можете обнаружить, что сделанные вами настройки может и помогли машине работать быстрее, но остальные машины этого хоста или кластера значительно просели по производительности. А вернуть все назад может быть не так уж и просто.

Недавно мы писали о том, как настроить сетевое соединение между Compute Network и SDDC Management Network в публичном облаке VMware vCloud on AWS (VMConAWS). Сегодня мы расскажем еще об одной полезности, предложенной Вильямом Ламмом - развертывании виртуального модуля VMware vCenter Server Appliance (VCSA) в такой инфраструктуре.

Начать надо с того, что когда вы запустите графический установщик виртуального модуля vCSA в среде VMC, то получите вот такое сообщение об ошибке на этапе указания параметров хоста для развертывания:

User has no administrative privileges

Это интересно тем, что на самом деле установщик vCSA не требует административных привилегий и, по идее, не должен выдавать такого сообщения об ошибке. Поэтому Вильям нашел, все-таки, способ развернуть vCSA в публичном облаке.

Для этого надо сделать следующее:

1. Создать вспомогательную ВМ (например, с Windows 10 на борту), которая будет использовать для развертывания нового экземпляра vCSA с помощью командной строки. Вы можете использовать для этой цели любую ОС, которая поддерживает интерфейс vCSA CLI.

2. Настроить соединение между сетевыми экранами Management (MGW) и Compute (CGW) для этой машины, как мы писали вот тут, чтобы установщик имел доступ к административной сети. 

3. Развернуть vCSA через CLI с помощью файла конфигурации развертывания в формате JSON, настроенного под ваше окружение. Вот пример содержимого такого файла, который вы можете взять за основу:

{
    "new_vcsa": {
        "vc": {

            "hostname": "vcenter.sddc-a-b-c-d.vmwarevmc.com",
            "username": "cloudadmin@vmc.local",
            "password": "FILLMEIN",
            "deployment_network": "sddc-cgw-network-1",
            "datacenter": [
                "SDDC-Datacenter"
            ],
            "datastore": "WorkloadDatastore",
            "target": [
                "Cluster-1",
                "Resources",
                "Compute-ResourcePool"
            ]
        },
        "appliance": {
            "thin_disk_mode": true,
            "deployment_option": "tiny",
            "name": "VCSA-67u2"
        },
        "network": {
            "ip_family": "ipv4",
            "mode": "dhcp"
        },
        "os": {
            "password": "VMware1!",
            "time_tools_sync": true,
            "ssh_enable": true
        },
        "sso": {
            "password": "VMware1!",
            "domain_name": "vsphere.local"
        }
    },
    "ceip": {
        "settings": {
            "ceip_enabled": false
        }
    }
}

После этой процедуры вы получите работающий VMware vCenter Server Appliance 6.7 Update 2 в своей инфраструктуре, который сможете использовать как для тестирования его возможностей, так и для полноценного управления виртуальной средой:

Не так давно мы писали о функции Site Locality в кластере VMware vSAN и некоторых ситуациях, когда эту функцию полезно отключать. Недавно Дункан Эппинг еще раз вернулся к этой теме и рассказал, что при использовании растянутых кластеров VMware vSAN надо иметь в виду некоторые особенности этого механизма.

При создании растянутого кластера вам предоставляют опции по выбору уровня защиты данных RAID-1 или RAID-5/6 средствами политики FTT (Failures to tolerate), а также позволяют определить, как машина будет защищена с точки зрения репликации ее хранилищ между датацентрами.

Некоторые дисковые объекты машин вы можете исключить из растянутого кластера и не реплицировать их между площадками. Такая настройка в HTML5-клиенте выглядит следующим образом:

В старом интерфейсе vSphere Web Client это настраивается вот тут:

Смысл настройки этих политик для виртуальной машины в том, чтобы вы могли однозначно определить размещение ее дисковых объектов, так как если у нее несколько виртуальных дисков VMDK, то если вы не зададите их локацию явно - может возникнуть такая ситуация, когда диски одной машины размещаются в разных датацентрах! Потому что при развертывании ВМ решение о размещении принимается на уровне дисковых объектов (то есть на уровне виртуальных дисков), которые по каким-то причинам могут разъехаться в разные сайты, если вы выберите первый пункт на первом скриншоте.

Это, конечно же, со всех сторон плохо, особенно с точки зрения производительности.

Если такая машина работает не в растянутом кластере vSAN, то в случае, если произойдет разрыв между площадками - часть дисков в гостевой системе станет недоступна, что неприемлемо для приложений и ОС.

Поэтому всегда убеждайтесь, что машина и ее дисковые объекты всегда находятся на одном сайте, для этого задавайте их локацию явно:

Не смогли в этом году присутствовать на VeeamON Forum 2019 в Москве? Присоединяйтесь онлайн!

VeeamON Forum Москва 2019 - крупнейший форум по интеллектуальному управлению данными - состоится 6 июня.

В программе:

• Выступления Дэниэла Фрида, генерального директора и старшего вице-президента в регионе EMEA, и Василия Ваганова, вице-президента по Восточной Европе, России, СНГ и странам Ближнего Востока.
• Представители Hewlett Packard Enterprise, NetApp, Lenovo, PureStorage, Nutanix расскажут об эволюции в управлении данными.
• Технические сессии, включая обзор архитектуры, планирования и установки для Veeam Backup for Microsoft Office 365, тонкости проектирования комплексной платформы Veeam с более 25.000 виртуальных машин, и многое другое.

Полный перечень выступлений. Трансляция сегодня доступна по этой ссылке.

Для многих пользователей публичного облака VMware vCloud on AWS одним из первых возникает вопрос - как предоставить доступ из виртуальной машины в сети Compute Network в сеть SDDC Management Network, например, для целей управления сервисами vCenter или другими службами виртуального датацентра?

Также этот вариант использования может быть востребован, когда вам требуется доступ к управляющим компонентам посредством таких интерфейсов, как PowerCLI, или развертывание виртуальных сервисов с помощью утилиты OVFTool. Вильям Лам написал об этом хорошую статью, и мы приведем здесь ее основные моменты.

Естественно, что для целей обеспечения безопасности в облаке, эти две сети по умолчанию разделены. Первое, что вам нужно сделать - это понять, с каким типом решения NSX для управления сетью вы работаете (NSX-T или NSX-V). Сделать это можно с помощью вот этой статьи.

Процедура для NSX-V

В среде NSX-V вам нужно настроить IPsec VPN между компонентами Management Gateway (MGW) и Compute Gateway (CGW) перед тем, как заработает коммуникация между сетями.

Для настройки VPN для компонента Management Gateway нажимаем Add VPN в консоли VMC и вводим требующуюся информацию сетевой идентификации (публичный IP удаленного шлюза, параметры удаленной сети и ключи), что должно отражать конфигурацию Compute Gateway (остальные настройки можно оставить по умолчанию).

Далее надо настроить VPN для Compute Gateway путем выполнения тех же шагов, что и в предыдущем абзаце, только указав конфигурацию шлюза Management Gateway. После того, как настройки обеих VPN будут сохранены, начнет отображаться статус "Partially Connected". Потом нажимаем ссылку Actions в правом верхнем углу, выбираем Edit и сохраняем настройки еще раз, чтобы на обоих шлюзах показался статус "Connected":

Теперь надо настроить сетевой экран Compute Gateway Firewall, чтобы разрешить исходящие соединения в SDDC Management Network по порту 443 для требуемых ВМ (этот порт используется для vSphere Client, а также для доступа через средства OVFTool и PowerCLI).

В приведенном ниже примере машина имеет адрес 192.168.1.4, и мы хотим позволить ей общаться с сетью 10.2.0.0/16 через порт 443:

Теперь нужно добавить в фаервол Management Gateway Firewall правила для разрешения входящих соединений для vCenter Server и хостов ESXi по порту 443 от наших определенных ВМ. Здесь все точно так же - указываем IP машины 192.168.1.4, и нам нужно добавить 2 правила для входящего трафика для разрешения коммуникации со средствами управления виртуальной инфраструктурой:

После этого вы можете залогиниться в виртуальную машину и использовать средства управления платформой vSphere, например, применять утилиту импорта виртуальных модулей OVFTool, как рассказано тут.

Процедура для NSX-T

В среде NSX-T вам не нужно создавать VPN для получения функциональности маршрутизации, которая изначально заложена в маршрутизаторе T0, ведь обе сети Management и Compute Network присоединены к T0. Между тем, правила сетевого экрана добавлять, конечно же, нужно.

В решении NSX-T используются сущности Inventory Groups, чтобы сгруппировать набор виртуальных машин и/или IP-адреса/сети, которые можно использовать при создании правил сетевого экрана.

Создаем две Inventory Groups для нашей Compute Group - одну для нашей виртуальной машины и одну для того, чтобы представлять сеть Management Network. Идем в Groups и в левой части выбираем пункт "Workload Groups", где создаем 2 группы:

• Windows10 с Member Type вида Virtual Machine и указываем ВМ из инвентаря.
• VMC Management Network с Member Type вида IP Address и указываем сетевой диапазон 10.2.0.0/16.

Теперь нужно создать еще одну Inventory Group для нашей Management Group, которая будет отражать ВМ, для которой мы хотим сделать доступ. Чтобы это сделать, идем в Groups, выбираем "Management Groups" и создаем следующую группу:

• Windows10 Private IP с Member Type вида IP Address и указываем частный IP-адрес ВМ (в данном случае это 192.168.1.2).

Не забывайте нажать кнопку Publish, чтобы сохранить и применить правило сетевого экрана.

Теперь нужно создать правило сетевого экрана, чтобы разрешить Compute Gateway исходящие соединения к SDDC Management Network по порту 443 для нужных ВМ. Идем в Gateway Firewall и выбираем "Compute Gateway", где создаем новое правило, которое отражает группу Windows 10 как источник и группу VMC Management Network как назначение, а в качестве сервиса выбираем HTTPS (помним также про кнопку Publish).

Теперь надо создать правила на уровне Management Gateway, чтобы разрешить входящие соединения к хостам vCenter Server и ESXi по порту 443 из нужных нам ВМ. Идем в Gateway Firewall, слева выбираем "Management Gateway", затем создаем правило, которое отражает группу Windows 10 как источник, а в качестве группы назначения указываем vCenter и ESXi (сервис ставим также HTTPS):

После выполнения этой процедуры вы сможете залогиниться в ВМ Windows и использовать утилиту OVFTool для импорта/экспорта ВМ в ваш виртуальный датацентр (см. также данную процедуру здесь).

Если все было сделано правильно, вы должны иметь возможность доступа к интерфейсу vSphere Client из нужной вам ВМ, а также возможность выполнять сценарии PowerCLI и использовать утилиту OVFTool, как показано на скриншоте ниже:

На сайте проекта VMware Labs появилось полезное администраторам решений vRealize Automation (vRA) и vRealize Orchestrator (vRO) средство vRealize Build Tools.

С помощью него разработчики и администраторы, работая совместно, смогут реализовать новые сценарии и рабочие процессы к vRA и vRO, используя стандартные практики DevOps. Пакет сфокусирован на качестве кода, его повторном использовании, модульном тестировании, управлении взаимосвязями и параллельных релизах проектов под платформу vRealize.

На практике vRealize Build Tools представляют собой расширения (extensions), упакованные в формат репозитория Maven, которые поддерживают использование IDE (через Maven), а также интерфейса CLI для разработки, тестирования и развертывания решений для платформ vRA/vRO. Также в пакет включен плагин к vRO, который предоставляет возможности автозаполнения для стандартных и сторонних объектов для сценариев и действий:

а также CLI-команды для развертывания пакетов к vRO/vRA через стандартные API:

Для начала работы с vRealize Build Tools вам понадобятся следующие инструменты:

• vRealize Orchestrator
• Microsoft VS Code
• vRealize Developer Tools

Скачать vRealize Build Tools можно по этой ссылке.

Те, кто используют серверы HPE ProLiant с гипервизором VMware ESXi и пакетом управления HPE Agentless Management (AMS) для кастомизированных образов ESXi от HP, могут столкнуться со следующим сообщением об ошибке в клиенте vSphere Client:

The ramdisk 'tmp' is full

Выглядит это чаще всего вот так:

Проблема актуальна для всех версий VMware ESXi 6.0, VMware ESXi 6.5 и VMware ESXi 6.7 с пакетом Agentless Management Service (AMS) версии 11.4.0.

Если зайти в консоль ESXi и выполнить там команду vdf, то можно увидеть, что раздел /tmp заполнен на 99%:

В самом же разделе tmp есть файлик ams-bbUsg.txt, который и является источником проблем:

Для временного решения этой проблемы нужно просто удалить этот файлик, и сообщения об ошибке прекратятся. Но чтобы этого не происходило, надо обновить ваш пакет HPE Agentless Management (AMS) версии 11.4.0, где проявляется данная проблема, на версию 11.4.2. О том, как это сделать написано в статье базы знаний HP:

Advisory: VMware - VMware AMS Data File Filling Up Tmp May Cause VUM Updates to Fail On HPE Servers Running VMware ESXi 6.0/6.5/6.7 with AMS Version 11.4.0.

Сам репозиторий с обновленным AMS находится по следующей ссылке:

http://vibsdepot.hpe.com/hpe/may2019

Если вы давно используете решение для организации инфраструктуры виртуальных ПК VMware Horizon, то, возможно, вам уже надоела картинка на бэкграунде формы доступа пользователей через веб-интерфейс:

Чтобы сменить эту картинку с облаками, на Connection Server идем в папку:

C:\Program Files\VMware\VMware View\Server\broker\webapps\portal\webclient\icons-6510409

Находим там файл bg_image и заменяем на новый (его разрешение 2560x1440):

Перезапускаем службу Horizon View Connection Server Service, после чего при заходе на View Connection Server через браузер мы увидим новый бэкграунд:

На сайте проекта VMware Labs появилась новая интересная штука - пакет разработки для автоматизации облачных сервисов Cloud Automation Services SDK for Python.

Данный SDK представляет собой набор классов Python, предназначенных для автоматизации различных операций на уровне компонентов Cloud Assembly, Service Broker и Code Stream API при разработке новых инструментов, дополняющих средства управления облачной средой.

Для начала работы вам понадобится:

• Cloud Automation Services for Python SDK Fling, скачанный из репозитория на GitHub
• Python версии 3 (минимально 3.6)
• Сгенерированный Cloud Services Platform API Key

Установка пакета проста:

• Клонируем гит-репозиторий командой git clone https://github.com/vmware/caspyr
• В склонированной папке устанавливаем модули командой python3 setup.py install
• Смотрим примеры использования в официальном репозитории

P.S. На момент написания этой заметки репозиторий на GitHub был еще недоступен - видимо надо немного подождать.

Вчера мы писали об ограничениях технологии Persistent Memory в vSphere 6.7, которая еще только изучается пользователями виртуальных инфраструктур на предмет эксплуатации в производственной среде. Преимущество такой памяти - это, конечно же, ее быстродействие и энергонезависимость, что позволяет применять ее в высокопроизводительных вычислениях (High Performance Computing, HPC).

Ну а пока все это изучается, сейчас самое время для проведения всякого рода тестирований.

На днях VMware выпустила документ "Persistent Memory Performance in vSphere 6.7 with Intel Optane DC persistent memory", где как раз тестируется память PMEM. Сейчас на рынке представлено всего 2 таких решения:

• NVDIMM-N от компаний DELL EMC и HPE. NVDIMM-N - это такой тип устройств DIMM, который содержит модули DRAM и NANDflash на самом DIMM. Данные перемещаются между двумя этими модулями при запуске или выключении машины, а также во время внезапной потери питания (на этот случай есть батарейки на плате). На текущий момент есть модули 16 GB NVDIMM-Ns.
• Intel Optane DC persistent memory (DCPMM) - эта память не такая быстрая как DRAM и имеет бОльшие задержки, но они измеряются наносекундами. Модули DCPMM изготавливаются под разъем DDR4 и доступны планками по 128, 256 и 512 ГБ. В одной системе может быть до 6 ТБ памяти DCPMM.

Для тестирования производительности такой памяти были использованы следующие конфигурации тестовой среды:

При тестировании производительности ввода-вывода были сделаны следующие заключения:

• Накладные расходы на поддержку PMEM составляют менее 4%.

• Конфигурация vPMEM-aware (когда приложение знает о vPMEM устройстве) может дать до 3x и более прироста пропускной способности в смешанном потоке чтения-записи в сравнении с традиционными устройствами vNVMe SSD (они использовались в качестве базового уровня).

• Задержки (latency) на уровне приложений для конфигураций vPMEM составили менее 1 микросекунды.

Также тестировалась производительность баз данных Oracle, и там были сделаны такие выводы:

• Улучшение на 28% в производительности приложения (количество транзакций HammerDB в минуту) с vPMEM по сравнению с vNVME SSD.

• Увеличение 1.25x DB reads, 2.24x DB writes и до 16.6x в числе записей в DB log.

• До 66 раз больше уменьшение задержек при выполнении операций в Oracle DB.

В MySQL тоже весьма существенное улучшение производительности:

Для PMEM-aware приложений тоже хорошие результаты:

Ну а остальные детали процесса проведения тестирования производительности устройств PMEM вы найдете в документе VMware.

В августе прошлого года мы сделали статью о новом виде памяти Persistent memory (PMEM) в VMware vSphere, которая находится на уровне между DRAM и Flash SSD с точки зрения производительности:

Надо сказать, что устройства с Persistent Memory (они же, например, девайсы с Intel Optane Memory) уже начинают рассматривать некоторые пользователи для внедрения в своей виртуальной инфраструктуре, поэтому надо помнить об их ограничениях, которые раскрыл Дункан Эппинг.

С точки зрения предоставления памяти PMEM виртуальной машине, на платформе vSphere есть 3 способа:

• vPMEMDisk - vSphere представляет PMEM как обычный диск, подключенный к виртуальной машине через контроллер SCSI. В этом случае ничего не нужно менять для гостевой ОС или приложений. В таком режиме работают любые системы, включая старые ОС и приложения.
• vPMEM - vSphere представляет PMEM как устройство NVDIMM для виртуальной машины. Большинство последних версий операционных систем (например, Windows Server 2016 и CentOS 7.4) поддерживают устройства NVDIMM и могут предоставлять их приложениям как блочные или байт-адресуемые устройства. Приложения могут использовать vPMEM как устройство хранения через тонкий слой файловой системы direct-access (DAX), либо замапить регион с устройства и получать к нему прямой доступ через байтовую адресацию. Такой режим может быть использован старыми или новыми приложениями, но работающими в новых версиях ОС, при этом версия Virtual Hardware должна быть не ниже 14.
• vPMEM-aware - это то же самое, что и vPMEM, но только с дополнительными возможностями приложения понимать, что машина использует такое устройство, и пользоваться его преимуществами.

Если виртуальная машина использует такие устройства, то она имеет очень существенные ограничения, которые на данный момент препятствуют их использованию в производственной среде. Они приведены в документе "vSphere Resource Management Guide" на странице 47 внизу. А именно:

• vSphere HA - полностью не поддерживается для машин с включенными vPMEM устройствами, вне зависимости от режима использования.
• vSphere DRS - полностью не поддерживается для машин с включенными vPMEM устройствами (машины не включаются в рекомендации и не мигрируют через vMotion), вне зависимости от режима использования.
• Миграция vMotion для машин с устройствами vPMEM / vPMEM-aware доступна только на хосты с устройствами PMEM.
• Миграция vMotion машин с устройством vPMEMDISK возможна на хост без устройства PMEM.

Будем надеяться, что эта ситуация в будущем изменится.

Начиная с VMware vSphere 6.7, компания VMware поддерживает технологию защищенной виртуализации Virtualization-Based Security (VBS). Это один из механизмов, который позволяет предоставлять пользователям более защищенные рабочие Windows-среды средствами технологий Device Guard и Credential Guard (последняя предназначена для изоляции пространства хранения учетных записей от потенциальной кражи вредоносным ПО). Эти функции очень важны для защиты, например, таких компонентов инфраструктуры, как серверы Active Directory.

Между тем, с виртуальными машинами, работающими с поддержкой данной технологии, была найдена серьезная проблема - они зависают или выпадают в синий экран смерти (BSOD) при загрузке. Баг проявляется при включенной технологии VBS (на скриншоте vSphere Client на базе HTML5 с Hardware Version 14):

Также этот баг актуален и для включенной поддержки технологии I/O MMU:

Возможность VBS доступна в Microsoft Windows 10/2016/2019, сам же баг стал проявляться, начиная с версии Windows Insider Build 18362. VMware говорит, что проблема находится на стороне Microsoft, но оба вендора совместно работают над выпуском патча для ОС.

Статья базы знаний VMware KB 68043 содержит вопросы, которые позволят вам определить, затрагивает ли вас проблема.

Помимо проверки настроек в интерфейсе vSphere Client, которые вы видите на скриншотах выше, можно использовать вот такой PowerCLI-скрипт для определения машин, которые затрагивает проблема:

Get-View -ViewType VirtualMachine | Where {(($_.Config.Flags.VbsEnabled -eq "True") -or ($_.Config.Flags.VvtdEnabled -eq "True")) -and ($_.Summary.Config.GuestID -like "windows9*")} | Select Name,@{Name=”VBS”; Expression={$_.Config.Flags.VbsEnabled}},@{Name=”IOMMU”; Expression={$_.Config.Flags.VvtdEnabled}}

После того, как вы найдете у себя такие ВМ, то выхода у вас два:

• Не использовать VBS и I/O MMU для виртуальных машин.
• Использовать workaround, который приведен в статье KB 68043.

Workaround заключается в следующем:

• Выключаем машину и отключаем VBS и I/O MMU для нее.
• Устанавливаем ОС на ВМ или обновляем ее до самых последних апдейтов.
• Выключаем ВМ, выбираем в настройках "Expose hardware assisted virtualization to guest".
• Включаем ВМ, в настройках включаем функцию (feature) "Hyper-V" в гостевой ОС, после чего перезагружаем машину.
• Опять выключаем ВМ и включаем VBS и/или I/O MMU, после чего она уже будет нормально работать.

Помните, что такой Workaround не вечен для свежих установок, например, из образов 1903 & 19H1 DVD/ISO, так как следующее обновление потенциально может вернуть баг, который еще не пофикшен со стороны Microsoft. Имейте это в виду, когда создаете шаблоны виртуальных машин для массового развертывания. Поэтому сначала все обновляем до самой последней версии, потом уже используем Workaround выше.

Кстати, все могло бы быть и хуже) Например, уязвимость Remote Desktop Services vulnerability (CVE-2019-0708), требующая немедленного обновления не затрагивает системы с описанной проблемой выпадения в BSOD. Уязвимость с удаленным рабочим столом актуальна только для систем Windows XP, 7, Windows Server 2003, 2008 (+ R2), а баг с зависанием актуален только для более поздних Windows.

Ждем пока сделают нормальный фикс, и не надо будет плясать с Workaround'ом. А пока можете на всякий случай отключить VBS, если позволяют корпоративные политики.

Об утилите Horizon Migration Tool мы уже несколько раз писали, версия 2.3 которой вышла в марте 2017 года. Спустя более чем два года, компания VMware выпустила обновленную версию Horizon Migration Tool 3.0.2, которая стала доступной на сайте проекта VMware Labs.

Напомним, что средство Horizon Migration Tool предназначено для миграции виртуализованных приложений и десктопов с платформы Citrix XenApp на платформу VMware Horizon View. В процессе миграции одна ферма Citrix XenApp переносится в одну или несколько ферм VMware View.

Давайте посмотрим, что нового появилось за 2 года в данной утилите:

• Поддержка миграции с платформ Citrix на VMware Horizon 7.2.
• Добавлена возможность миграции пулов десктопов Citrix PVS на платформу Horizon 7.2.
• Добавлена возможность миграции пула Citrix Dedicate MCS Desktop Pool на платформу Horizon 7.2 как ручного пула (manual pool), пула связанных клонов (linked-clone pool) или пула мгновенных клонов (instant clone pool).
• Исправлен баг, когда приложения XenApp с кастомными путями, содержащими пробелы, не мигрировались корректно.

Не так уж и много, но хоть что-то. Скачать VMware Horizon Migration Tool 3.0.2 можно по этой ссылке.

Мы много писали об облачном решении VMware Cloud on AWS, которое было создано усилиями компаний Amazon и VMware.

В этом публичном облаке есть полезный механизм Log Intelligence, который позволяет посмотреть глубоко на метрики частного и публичного облака VMConAWS, чтобы выяснить причины возникающих проблем. Основное назначение этого механизма - структурировать неструктурированные данные логов, визуализовать их на дэшбордах и дать администратору инструменты быстрого поиска и сопоставления данных (включая мощный механизм индексирования).

Log Intelligence полностью интегрирован с облаком VMware Cloud on AWS, охватывает всю линейку продуктов VMware и органично дополняет концепцию управления виртуальным датацентром Software-Defined Datacenter (SDDC).

По умолчанию Log Intelligence собирает и анализирует все логи для основных компонентов (vCenter, ESXi, vSAN). Но также в решении есть функция аудита логов сетевого экрана виртуальной инфраструктуры NSX-T, которую можно подключить отдельно:

Для интеграции с NSX-T нужно будет подключить VMware Cloud on AWS Content Pack, который позволит получить информацию о правилах фаервола, правилах обработки пакетов и прочую важную диагностическую информацию для администраторов:

После развертывания можно будет увидеть все исполняемые в среде NSX-T запросы:

Также можно управлять определениями оповещений (Alert Definitions):

Запросы можно сохранить на собственных или общих дэшбордах, а также включить Alert Definitions для отправки webhook во внешнюю систему или письма по электронной почте администратору.

Вот пример двух запросов, сохраненных на дэшборде:

На домашней странице можно видеть сработавшие алерты в виде таймлайна:

Вот так выглядит оповещение в письме администратору:

А так, например, webhook в мессенжер Slack:

Решение Log Intelligence также может перенаправлять логи в другие приемники для специфического анализа (подробнее тут). Поддерживаются следующие точки назначения:

• Онпремизная инсталляция vRealize Log Insight
• Онпремизная инсталляция Syslog Server через TCP или UDP
• Онпремизная инсталляция Splunk
• Онпремизная отсылка по умолчанию через Authenticated HTTPs
• Облачный Splunk Cloud Endpoint
• Облачный Authenticated endpoint через протокол HTTPs

Для отправки логов в собственное онпремизное облако нужно будет развернуть Cloud Proxy:

Для облачного ничего добавлять не нужно:

События логов можно экспортировать в Raw-формате или в структуре JSON:

В общем, Log Intelligence может оказаться вам очень полезным в облаке VMware Cloud on AWS (или в гибридной среде с собственным датацентром), особенно, если ваша инфраструктура содержит десятки хостов ESXi.

На сайте проекта VMware Labs появилась новая интересная Open Source утилита - Distributed Trust Incident Reporting. Она предназначена для документирования инцидентов в сфере информационной безопасности, которое часто осуществляется на бумаге или в Excel даже в крупных компаниях. Некоторые системы имеют централизованную базу данных инцидентов с возможностью отслеживания ответных мер, принятых в качестве реакции на инцидент, но только на уровне собственного предприятия.

Текущие подходы по мнению VMware обладают рядом недостатков:

• Инцидент может затронуть несколько сущностей/компаний с разной ответственностью.
• Все они должны как-то отреагировать на него.
• Некоторые сущности не имеют доверия к другим.
• Нет одной стороны, которая отвечает за эксплуатацию всей системы с точки зрения безопасности.

Примером такого инцидента является нарушение процесса у производителя еды, в результате которого на полку розничной сети в продукт попадает опасный патоген. В этом случае следует серия звонков или писем от ритейлера к дистрибьютору, а далее к производителю, чтобы отреагировать на инцидент.

Утилита Distributed Trust Incident Reporting позволяет:

• Увидеть всем сторонам процесса зафиксированный инцидент.
• Позволяет всем сторонам отреагировать, как того требует ситуация и зафиксировать это.
• Принимает на вход отчеты информационных систем об инцидентах.
• Добавляет прозрачности между разными сущностями/организациями.

Работает это все на базе контейнеров Docker, а технологическую платформу фиксирования инцидентов предоставляют решения VMware blockchain или Ethereum blockchain.

Неясно, будет ли кто-то использовать эту систему от VMware, но, будем надеяться, она со временем интегрируется в существующую экосистему решений вендора для организации и эксплуатации виртуальной инфраструктуры на платформе vSphere.

Проект Distributed Trust Incident Reporting доступен для скачивания из репозитория GitHub.

Недавно мы писали о выходе обновленной версии решения для обеспечения катастрофоустойчивости виртуальных датацентров VMware Site Recovery Manager 8.2. Многие пользователи после ее релиза задались вопросом миграции на виртуальный модуль (Virtual Appliance), который построен на базе операционной системы Photon OS и управляется через веб-браузер.

Давайте вкратце рассмотрим этот процесс. В целом процедура миграции выглядит так:

• Убеждаемся, что ваш SRM на базе Windows обновлен до версии 8.2.
• Экспортируем конфигурацию и останавливаем SRM на хосте с Windows.
• Развертываем Site Recovery Manager Virtual Appliance и импортируем туда конфиг.

Пошагово этот процесс будет таким:

1. Логинимся в Site Recovery Manager for Windows, открываем командную строку и переходим в папку %SRM_INSTALL_DIR%\bin.

2. Запускаем следующий скрипт, он потребует ввод пароля администратора:

export-srm-data.bat

3. Экспортированную папку перемещаем на виртуальный модуль SRM.

4. Выключаем машину с SRM для Windows и логинимся как root в SRM VA.

5. Если вы создавали кастомные сертификаты, то их надо положить в папку /etc/ssl/certs (это файлы с расширением .pem). Импортировать сертификаты можно через Site Recovery Manager Appliance Management Interface.

Для изменения прав доступа к сертификатам используйте команду:

chmod a+r <new-root-ca>.pem

Далее выполните:

c_rehash

6. После этого запустите импорт окружения SRM, указав папку, которую вы экспортировали из Windows-окружения:

/opt/vmware/srm/bin/import-srm-data.sh <export_dir>

7. Вас попросят пароль администратора vCenter Single Sign-On, root виртуального модуля, а также пароль от файла, который был задан при экспорте конфигурации.

8. На вкладке Home веб-консоли решения SRM VA выберите импортированную пару сайтов и нажмите Actions > Reconnect. Выберите первый сайт из списка, введите адрес Platform Services Controller сервера SRM на резервной площадке и введите имя пользователя и пароль.

9. Далее вас попросят выбрать сервер vCenter, который нужно настроить и его сервисы, где вы просто нажимаете Next, а потом Finish.

Также весь этот процесс описан вот тут.